Release 10.1A: OpenEdge Development:
Progress Dynamics Advanced Development

Client-side code in a distributed application

Progress Dynamics is designed in every way to support distributed applications, where the user interface runs in a client session separate from an AppServer™ session that is connected to the database. This means that direct database references must be avoided completely in any Progress 4GL code to be executed on the client. It means that client-side events that force an AppServer call to retrieve information should be kept to a minimum for the best performance. It also means that, in general, client-side executable code should be kept to a minimum to reduce the number of procedures that must be deployed to client machines to run the application.

So,if client-side code cannot reference the database and should not call back to the AppServer except when necessary, what remains for the client code to do?

There are still likely to be many instances in which something particular to your application has to happen on the client, for example, an event that is triggered on the client and must be responded to on the client. On CHOOSE of a button, your code might need to check the value of the field and enable or disable other fields on the screen, or enable or disable menu items or buttons for certain related actions. You might need to modify the interface details of the screen in other ways, modifying colors depending on field values, displaying related text, and so on. These are all legitimate actions that rightly belong in the client-side code.

In some cases it is also necessary to make a call back to the server to obtain information or cause a server-side database action. As noted, these calls should be kept to a minimum to keep application performance from suffering in a widely distributed application, where every AppServer hit is costly. Generally, the amount of data passed between client and server is less of a performance issue than the number of AppServer requests, so keep this in mind when you are developing your code. If a data value that a user enters into a field requires that related data be retrieved from the server, and if this cannot be done until the field value is known, then go ahead and do it. If there are toolbar buttons or menu items, or other buttons in your application screens that retrieve data from the AppServer, then you can provide trigger code to handle this. Just ask yourself in each case whether the call is really necessary, and whether it can be combined with other calls.

This might mean a major adjustment in your thinking, especially for developers who have created host-based or client/server applications in earlier versions of OpenEdge, where the user interface logic is usually compiled right into the user interface itself, and where the database is always available for immediate access. In this environment, it is simple and appropriate to write field validation trigger code in the Data Dictionary that is compiled into the procedure along with the frame that contains the field. This code is executed ON LEAVE OF every field in the frame that has validation logic. It makes a reference to the database, often to do a CAN-FIND to make sure that a value typed into a foreign key field (such as Order.CustNum in the Sports2000 database) is a valid value from another table (such as Customer.CustNum).

In a distributed environment, making a call to the database means making a call to a separate server session, and doing this ON LEAVE OF many fields on a screen would incur a terrible performance cost. This does not mean that users are left without the feedback and validation they are used to from older applications. It simply means that your application design has to take a different approach to providing this kind of feedback. The dynamic lookups and combos in Progress Dynamics are one mechanism for providing and improving on CAN-FIND support without the immediate database lookup. A dynamic combo provides a list of all possible values for a field, assuring that the user will choose one correctly, and the lookup does the same for larger data sets, going back to the server only if the data set is too large to retrieve in a single batch and is not already cached on the client.

In other cases, calculations that might have been done on the fly in the user interface code in an earlier application can be done in advance and sent as calculated fields in the SDO in a single call, along with the rest of the data.

Another consideration is that code that requires database access on the client, apart from the integrity checks that combos and lookups do, is likely really business logic of one kind or another. Putting code of this type on the client violates another principle of distributed application: that business logic belongs on the server, either in SDOs (and their logic procedures), SBOs, or other procedures that can be accessed from anywhere on the client. Embedding business logic in the UI means that it will not be automatically executed from some alternative UI, whether it is another screen in the same application or an alternative UI altogether, such as for a Web browser interface. It also adds to the maintenance headaches you face when you have to modify your application’s behavior.

In any case, the following basic goals remain the same:

Minimize special code written for the client.
Minimize unnecessary AppServer calls.
Keep business logic out of the client code altogether, whenever possible.